Deavmi's coding shack
Commit d8a852b06eb92b6c85603cd070980a8092503878
Parents : 8641b2e
Author : Tristan B. Kildaire <deavmi@redxen.eu>
Date : 2021-03-27T16:05:43+02:00
Added new update
Changes
Diff
diff --git a/docs/journal/update-1.md b/docs/journal/update-1.md
new file mode 100644
index 0000000..750907c
--- /dev/null
+++ b/docs/journal/update-1.md
@@ -0,0 +1,95 @@
+Major update - grind of a week
+==============================
+
+The title makes no sense.
+
+I have a raging foot fetish.
+
+I have failed no nut november.
+
+There are SSA agents outside my window looking at me whilst I poo.
+
+Date: 27th of March 2021
+
+A summary of the things I have worked on this week.
+
+# Parser
+
+The parser has had **a lot** of updates added to it. Namely I have added the following:
+
+* Class parsing
+ * This includes with or without inheritance/impentation (as in expecting the names and comma seperation)
+* If statement parsing
+ * This inludes with else if and else
+* Module header is now required as the first statement
+
+## Data structure generation
+
+For many aspects of the program we represent them as some sort of `Statement`, of which we have sub-classes of
+like `Entity` and `TypedEntity` (of which `Function` and `Variable` are kinds-of).
+
+We also put these in a tree, by chainging objects toghether and such. And then all top-level `Statement`s
+are put into `Statement[]` in the `Program` object (which should rather be named `Module` probably).
+
+# Type-checker
+
+I have started work on playing around with the generated program structures.
+
+## Dot-path resolver
+
+One thing I have worked on that started working is for checking if a given identifier exists based on a dot-seperated path (which makes sense when you have
+classes and such as you could have a variable named `x` stored in class `clazz` and accessing it from the outside
+would require `clazz.x`). A note to make about this is I need to edit the lexer to allow for tokenising those sequences
+with dots in them.
+
+So given the path `clazz.x` it will return the `Variable` object `x` within the `Clazz` object, `clazz`. In the case resolution
+fails then a `null` reference is returned.
+
+## What's next
+
+A few things going between the parser and type-checker and seeing where their best placement would be. Then I think
+actual name checking, expression resolution (for types) and checking that against variable types can begin and we can
+get to work on the chunky work. But it will take some time. One thing I also need to do is replace the `expect(type)`
+with basically the same code as `expect(identifier)` (once the aforementioned `x.x` lexer addition is added).
+
+The reason for this is given the follow code example:
+
+```
+class D
+{
+ static int a;
+}
+```
+
+You would agree that the variable `a` would be a valid identifier as `D.a`, perhaps when resolving an expression that
+includes it.
+
+You would also agree then that I should be able to declare a variable, say now named `y` of type `P` if I had the below
+given code:
+
+```
+class D
+{
+ class P
+ {
+
+ }
+}
+```
+
+You would agree then if my variable was at the global level, not within `P` or within `D` that to access the type `P` I would
+need to use the path of `D.P` as follows:
+
+```
+D.P y;
+```
+
+Hence it really follows the same form as `expect(identifier)` then. I shouldn't be attempting to validate what a valid type
+is during parsing anyways, only a valid possible form.
+
+However here is something I just thought of. I cannot allow classes to be defined with dots in them or the variable's themselves.
+
+> I guess it's usage v.s. declaration
+
+What I will create is an `expect(IDENT_USAGE)` (which will allow dotted-or-non-dotted) and then `expect(IDENT_DEC)` (which will be
+solely non-dotted).
\ No newline at end of file
diff --git a/mkdocs.yml b/mkdocs.yml
index 482be09..7c59fc3 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -14,5 +14,6 @@ nav:
- journal/parsing-begins.md
- journal/parser-update-1.md
- journal/parser-update-2.md
+ - journal/update-1.md
theme: sandstone
\ No newline at end of file
Served by rngit 1.5.0 - Generated in 0.11s